1. Field of the Invention
The present invention relates generally to a method for communications using the Transmission Control Protocol (“TCP”), and more specifically, it relates to a method for splitting data and acknowledgements in a TCP session.
2. Description of Related Art
The Transmission Control Protocol (TCP) is a communications protocol that is used in communicating data over a network, such as the Internet. It is a connection-oriented protocol in the transport layer. Used in conjunction with other protocols, such as the Internet Protocol (IP), TCP provides a format for breaking a data message into segments, transmitting the segments over the network, and reassembling the segments to form the original data message.
When a connection is established between two devices, they exchange data by sending segments. Data to be sent is split into fragments, which are then formed into the segments according to specific transmission protocols. The segments are transmitted using TCP/IP and other protocols. The segments may travel over many different links and through routers or other elements before reaching their destination. Since segments may take different paths, they may arrive at the receiver out of order. It is also possible that segments are lost during transmission. TCP provides methods for reassembling segments that arrive out of order and for retransmitting segments that are lost during transmission.
If segments are lost, then the data message cannot be properly reassembled at the receiver, because the receiver will not have all the data. TCP compensates for possible segment loss by having the receiver acknowledge each segment. If an acknowledgement is not received in a specified time after transmission, the transmitter assumes that the segment has been lost and resends the segment.
Each segment sent by the transmitter has a unique identifier. The identifier allows the transmitter and receiver to individually identify each segment. Typically the transmitter sends a certain amount of data and waits for an acknowledgement before sending more data. The receiver acknowledges the segments by sending the transmitter a TCP segment with an acknowledgement bit set and the number of the next segment it expects to receive. By specifying the next segment it expects to receive, the receiver implicitly acknowledges the successful receipt of all previous segments. This format allows the receiver to acknowledge several segments with one acknowledgement; however, the process prevents a receiver from acknowledging a successfully received segment unless all the segments before it were also successfully received. The receiver may piggyback the acknowledgement onto a data segment sent from the receiver to the transmitter.
The data speeds along links between the transmitter and receiver may not be balanced. Data may travel faster in one direction than in the other direction. This may be due to the bandwidth on different segments, the amount of network traffic, router settings or other factors. Typically, when a transmitter sends data it sends a specified amount and waits for an acknowledgement before sending more. The amount of data that can be sent and unacknowledged is set by the system, and it may vary during operation.
A transmitter sends the maximum amount of data allowed by the transmit window. It then stops transmitting and waits for an acknowledgement specifying a new transmit window. If the data path from the transmitter to receiver is fast, all the data may have successfully reached the receiver and the system could support more data; however, since the acknowledgement is slow reaching the transmitter, it unnecessarily sits idle resulting in a delay. The delay may eventually allow the transmitter's timer to expire, which causes the transmitter to unnecessarily resend the segments. These undesirable effects slow the overall data transmission rate.
A similar problem can also occur in Quality of Service (QoS) systems. In a QoS system several sessions may simultaneously occur. Each session is assigned a priority, and sessions with a higher priority receive a greater allocation of system resources. Messages with a higher priority may also get a transmission preference in routers and other components. The higher bandwidth of these messages is at the expense of lower priority messages, which may be delayed. In sessions with lower priority, the acknowledgements may be delayed because higher-priority messages are using the available system resources. The delay may be significantly greater along the acknowledgement path than the data path. The data path may be available for transmission, but due to the delayed acknowledgement the transmitter remains unnecessarily idle.
Some systems attempt to solve this problem by lowering the maximum transmission unit (MTU) of the link. The MTU is the largest physical segment size the network can transmit. Lowering this value may reduce the maximum time required to receive a segment, thereby minimizing the delay in receiving a piggyback acknowledgement. This solution, however, requires user or administrator configuration to change the MTU value, and it introduces significant overhead. By lowering the maximum size of a segment, more segments are required to transmit the same amount of data. The network will take longer to process the additional segments, and the headers of the additional segments means that more total bits have to be sent over the network to support the same amount of data. Additionally, reducing the MTU doesn't prevent TCP window closure when higher priority traffic precludes sending low-priority data.
Therefore, there exists a need to provide a better way to improve the quality of service of a TCP session when reverse direction congestion delays piggybacked acknowledgements and prevents data transmission.